Domain names in a network are managed by the Domain Name System (DNS) architecture defined by Request For Comments (RFC) 1034 issued by the Internet Engineering Task Force (IETF).
That architecture introduces the concept of a “domain”, consisting of a group of machines in the network.
FIG. 1 shows such an architecture. The domains ., .fr, .com, ft.com, and rd.ft.com contain sub-domains.
For example, the domain ft.com includes three sub-domains user.ft.com, rd.ft.com, and www.ft.com.
The domains that are underlined in FIG. 1 are known as “terminal domains”. A terminal domain can represent one or more physical machines, which is the case of the terminal domain www.rd.ft.com, for example, which in this example is a web server, but can also not represent a physical machine, which is the case of the terminal domain user.ft.com, for example, which in this example consists of personal information of the user denoted “user”.
A domain that includes one or more sub-domains is associated with a domain server.
That domain server includes a zone file.
Domains are logically interlinked so that DNS data of any domain can be obtained by submitting queries to the name servers progressively (in other words, from “parent” to “child”), beginning with the root server.
The “DNS data” referred to in RFC 1034 can in particular represent an IP (Internet Protocol) address of a domain, a text, or any field associated with a domain.
Unfortunately, the DNS architecture has certain security weaknesses.
For example, when a user logs onto a website to effect a banking transaction, there is no way to be sure that he is actually connected to the required site, rather than to a pirate site attempting to obtain their banking information by fraud.
IETF RFC 4033, RFC 4034 and RFC 4035 define a secure extension of the DNS protocol, known as the “DNSSEC” protocol. Returning to the previous scenario, the DNSSEC protocol guarantees that users are actually connected to the required website.
To be more precise, the DNSSEC protocol guarantees the integrity of DNS data by using signatures to encrypt it.
Thus a domains managed by a domain name server is characterized by a pair of public key/private key pairs denoted ZSK (Zone Signing Key); the public and private components of this pair are respectively denoted ZSK[pu] and ZSK[pr]. A user who has submitted a query to a DNS server using the DNSSEC protocol to obtain DNS data (referred to generically as RR DATA) receives in return from the server the required data RR DATA and the value of the RR DATA signature effected by means of the private key ZSK[pr].
A user can in particular submit a “KEY” query. Under such circumstances, as described above, the user obtains the key ZSK[pu] in clear and the value of the signature produced using the private key ZSK[pr]; however, the user also receives the public component KSK[pu] of a key pair denoted KSK (Key Signing Key) and the value of the signature of the keys ZSK[pu] KSK[pu] produced by means of the private component KSK[pr] of this KSK pair. By submitting queries to the “parent” domain of the domain concerned, users can authenticate the key KSK[pu] and consequently authenticate the key ZSK[pu] which, in the end, enables them to verify the signature of any DNS data from the domain concerned.
The DNSSEC protocol therefore establishes a chain of trust in the hierarchy of domains.
Conventional implementation of this protocol has the drawback that the operation of signing all the DNS data of a given domain is costly for the domain manager in terms of resources. Moreover, on renewing a ZSK pair, the signatures of all the data signed with the key ZSK[pr] must also be renewed, which is very costly in terms of computation time.